[% setvar title The Perl 6 Summary for the week ending 2004-09-03 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the week ending 2004-09-03'></a><h1>The Perl 6 Summary for the week ending 2004-09-03</h1>
<p>Another week, a free weekend, and still I haven't started writing the
summary until Monday. Still, I don't actually start at college 'til
next week, so that's all right then.</p>
<p>We start with perl6-internals.</p>
<a name='Compile op with return values'></a><h2>Compile op with return values</h2>
<p>The discussion of how to return something from dynamically compiled
code continued with Leo, Dan and Steve Fink all working to clarify and
address the issues.</p>
<p><a href='http://groups.google.com/groups?threadm=20040828065049.GC12318@kevin.fink.com' target='_blank'>groups.google.com</a></p>
<a name='Library loading'></a><h2>Library loading</h2>
<p>Dan started the process of nailing down Parrot's dynamic loading API so
that it can be added to the embedding interface. Steve Fink and Aaron
Sherman had suggestions.</p>
<p><a href='http://groups.google.com/groups?threadm=a06110410bd568c66e647@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<a name='Pathological register allocation scenarios'></a><h2>Pathological register allocation scenarios</h2>
<p>Gregor N Purdy had asked Dan if his work compiler could be made to spit
out structurally equivalent C code to the Parrot code that was breaking
IMCC. His idea being that we could then see how C compilers dealt with
such nastiness. Dan thought that, whilst this was a good idea, it would
be too much work to implement. Gregor wasn't so sure.</p>
<p><a href='http://groups.google.com/groups?threadm=a0611041abd58ca5c3463@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<a name='Dan and Leo demonstrate comic timing. Again.'></a><h2>Dan and Leo demonstrate comic timing. Again.</h2>
<p>14:17:09 GMT Dan: PerlHash test 20 is failing? Anyone know what's up so we
can fix it?</p>
<p>15:30:41 GMT Leo: It stopped failing at 15:55 CEST (13:55 GMT)</p>
<p>16:32:29 GMT Dan: D'oh!</p>
<p>We love it when a patch comes together.</p>
<p><a href='http://groups.google.com/groups?threadm=a06110422bd58e6de10f8@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<a name='PMC Instantiation'></a><h2>PMC Instantiation</h2>
<p>Leo had raised issues with the current scheme for PMC
instantiation. This week Dan came through with some design which got
discussed and (I think) implemented.</p>
<p><a href='http://groups.google.com/groups?threadm=a06110427bd590a576148@' target='_blank'>groups.google.com</a>[10.0.1.2]</p>
<a name='Last bits of the basic math semantics'></a><h2>Last bits of the basic math semantics</h2>
<p>If you believe Barbie, &quot;Math is hard&quot;. She's right, up to a point. The
list's spent a couple of weeks now sorting out the design of Parrots
underlying mathematical and numeric systems to make sure that maths
works right (for sufficiently useful values of 'right'). This
particular line of discussion covers rotations and stuff, where you're
actually treating a number as a bit field.</p>
<p><a href='http://groups.google.com/groups?threadm=200408310958.i7V9wN909589@thu8.leo.home' target='_blank'>groups.google.com</a></p>
<a name='Cross-compiling parrot'></a><h2>Cross-compiling parrot</h2>
<p>And you thought compiling Parrot on a Win32 box was hard. Robert
Schwebel wants to cross compile Parrot and isn't having a good
time. Dan wasn't surprised because the Parrot build process still gets
most of its information from the local perl installation which will
generally be wrong when you're cross compiling.</p>
<p>Dan noted that part of the problem is that we don't have people on the
team with a need or the experience of doing cross compilation and added
that he'd be thrilled if this were to change. Any patches to make
things better for cross compilers will, of course, be gratefully
received.</p>
<p><a href='http://groups.google.com/groups?threadm=20040901173244.GE1369@pengutronix.de' target='_blank'>groups.google.com</a></p>
<a name='Proposal for a new PMC layout and more'></a><h2>Proposal for a new PMC layout and more</h2>
<p>Leo's concerned that the current PMC layout isn't the Right Thing, and
laid out a proposal describing some changes he thinks would be
worthwhile. In essence, he argues for removing the requirement for
fixed sized PMC headers and separate variable sized buffers in favour
of unifying buffers and PMCs so that PMCs become variable sized, thus
eliminating some time consuming indirection, and space consuming
overheads.</p>
<p>Nicholas Clark thought the proposal was interesting, but said that,
since the proposed changes would be invisible to the user, he'd be far
happier with a functionally complete implementation of parrot with
stable, useful APIs.</p>
<p>Dan rejected the proposal (both for technical reasons and because he
agreed with Nicholas). I don't think Leo was convinced by the technical
reasons, but the &quot;Let's get the interfaces finished!&quot; argument clinched it.</p>
<p><a href='http://groups.google.com/groups?threadm=4135E823.7070902@toetsch.at' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=a0611040bbd5bb29d2c15@' target='_blank'>groups.google.com</a>[172.24.18.155] -- Dan explains why not.</p>
<a name='Semantics for regexes'></a><h2>Semantics for regexes</h2>
<p>Dan appears to have opened an entertaining can of worms when he
outlined his view of the minimum string semantics required to support a
regular expression engine and asked for comments. Boy did he get
them. And boy did they run off in all sorts of strange
directions. Interesting directions mind. Anyway, further down the
thread, Dan, Chip Salzenburg and Patrick Michaud seemed to reach
something approximating agreement about the low level semantics
required.</p>
<p><a href='http://groups.google.com/groups?threadm=a0611040ebd5bbe03d7e1@' target='_blank'>groups.google.com</a>[172.24.18.155]</p>
<a name='TODOs and calls for volunteers'></a><h2>TODOs and calls for volunteers</h2>
<p>Leo came up with a list of things that need fixing/implementing and
asked for volunteers. These include sorting out what happens with the
experimental ops, implementing <code>new_extended</code> for every PMC class and
finishing up BigInt's MMD and vtable functions.</p>
<p>He also had some proposals for how we should get the Integer classes
properly implemented now we know what the semantics will be.</p>
<p><a href='http://groups.google.com/groups?threadm=4137507F.5010606@toetsch.at' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=41385717.90803@toetsch.at' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=41385937.7020708@toetsch.at' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=200409031221.i83CLUv13413@thu8.leo.home' target='_blank'>groups.google.com</a></p>
<a name='Meanwhile, in perl6-language'></a><h1>Meanwhile, in perl6-language</h1>
<a name='Roles trying to be nice'></a><h2>Roles trying to be nice</h2>
<p>Abhijit Mahabal had some questions about making roles work. Luke,
Patrick &amp; Jonathan Scott Duff set about answering them. I'm not entirely
sure that any of the answers so far are enough for Abhijit, but then
I'm not entirely sure that any answer could be enough. At some point
you have to take things on trust and hope that nothing breaks at
runtime.</p>
<p><a href='http://groups.google.com/groups?threadm=Pine.GSO.4.58.0408292126230.10203@prickly.cs.indiana.edu' target='_blank'>groups.google.com</a></p>
<a name='Pipeline performance'></a><h2>Pipeline performance</h2>
<p>Rod Adams brought up some issues with the performance of 'pipelining'
arrays in Perl 5 -- in general doing say <code>grep {...} map {...} @ary</code>
is rather slower than writing an explicit loop. He wondered if Perl 6
would be faster. Larry's answer that all lists function lazily if they
can in Perl 6 seems to imply that yes, Perl 6 will be faster.</p>
<p><a href='http://groups.google.com/groups?threadm=41338F4C.2090300@rodadams.net' target='_blank'>groups.google.com</a></p>
<a name='Synopsis 9 draft 1'></a><h2>Synopsis 9 draft 1</h2>
<p>&quot;Synopsis 9?&quot; I hear you ask &quot;But we haven't seen Apocalypse 9
yet!&quot;. Indeed we haven't, but that's not stopped Larry writing
it. Synopsis 9 gives an overview of Perl 6's data structures (hopefully
enough for anyone who happens to be starting work on a rough cut of a
Perl 6 implementation) which will be covered in more detail when the
Apocalypse itself comes out.</p>
<p>The usual storm of discussion and general proofreading goodness went on.</p>
<p><a href='http://groups.google.com/groups?threadm=20040902234740.GA29156@wall.org' target='_blank'>groups.google.com</a></p>
<a name='The range operator'></a><h2>The range operator</h2>
<p>Joe Gottman wondered if there would be sufficiently lazy way to
generate ranges. In particular, he wanted to know if he'd be able to
write <code>reverse (1..5)</code> and have Perl handle that lazily, or if he
could do <code>5 .. 1 :by(-1)</code>. Larry thought that, if range objects were
made sufficiently smart, there would be no reason why the <code>reverse</code>
approach couldn't be lazy.</p>
<p><a href='http://groups.google.com/groups?threadm=200409030034.i830YESH008947@ms-smtp-04-eri0.southeast.rr.com' target='_blank'>groups.google.com</a></p>
<a name='Can PRE and POST be removed from program flow?'></a><h2>Can PRE and POST be removed from program flow?</h2>
<p>John Siracusa wondered if it would be possible to turn off the PRE and
POST Design By Contract hooks in production code to improve
performance. (Leaving aside arguments about whether this is sensible;
personally I reckon that a production environment is where you should
be most worried about values that might fail the PRE/POST hooks). Larry
reckoned it would be possible to simply clobber the global definitions
of PRE and POST to make them no ops. This wasn't enough for John, who
wanted to be able to get rid of them entirely so even the call to the
no op didn't happen. So Damian showed him the obvious macros...</p>
<p><a href='http://groups.google.com/groups?threadm=BD5E4DEC.1CB3A' target='_blank'>groups.google.com</a>%siracusa@mindspring.com</p>
<a name='Announcements, Apologies, Acknowledgements'></a><h1>Announcements, Apologies, Acknowledgements</h1>
<p>It looks like the Google groups gateway is working again, so I'll keep
with the Google style linking.</p>
<p>If you find these summaries useful or enjoyable, please consider
contributing to the Perl Foundation to help support the development of
Perl. You might also like to send feedback or contributions to a
'getting Piers to OSCON 2005' fund to mailto:<a href='mailto:pdcawley@bofh.org.uk'>pdcawley@bofh.org.uk</a></p>
<p><a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> -- The Perl Foundation</p>
<p><a href='http://dev.perl.org/perl6/' target='_blank'>dev.perl.org</a> -- Perl 6 Development site</p>
<p>Or, you can check out my website.</p>
<p><a href='http://www.bofh.org.uk/' target='_blank'>www.bofh.org.uk</a></p>
</div>
